Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix docstring issue and a broken link #1576

Merged
merged 17 commits into from
Jun 8, 2021
Merged

Conversation

lwasser
Copy link
Contributor

@lwasser lwasser commented May 17, 2021

When building the docs a few issues come up. One is a bad reference link that no longer exists on the page. Modified the link to be a jinja docs link for templates that works. The other is a docstring issue. will watch CI on this one and check back.

Copy link
Contributor

@MSeal MSeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for helping improve the docs. I'm not sure what the change was causing the 404 jinja requests in the past. Might be worth looking at build history to see when that shifted / broke as well.

@@ -186,6 +186,6 @@ which is used for serving `reveal.js`_ HTML slideshows.
.. links:

.. _jinja: http://jinja.pocoo.org/
.. _filter: http://jinja.pocoo.org/docs/dev/templates/#filters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm still seems to be complaining about pocoo.org fetches -- maybe the line before or somewhere else in the project we're fetching objects that don't exist anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes @MSeal ! i'm really confused about the CI issue. Here is what i know.

that url - jinja.pocoo.org/docs resolves to https://jinja.palletsprojects.com/en/3.0.x/

i've definitely seen builds have a hard time with redirects. i just fixed that but i'm still seeing that CI issue. i suspect somewhere there are other pocoo.org references perhaps? i can search for that next.

http://jinja.pocoo.org/docs/dev/objects.inv

i think i fixed it. the link for intersphinx_mapping was the old url. give me a few minutes to push it up. fingers crossed :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed this URL to be the new jinja docs link. palletsprojects.com

@@ -12,5 +12,6 @@ dependencies:
- tornado
- entrypoints
- ipykernel
- pip
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was merged in my last pr. speeds up the build and simplifies the uutput

@@ -151,7 +151,7 @@ Configurable classes.
.. seealso::

- :doc:`customizing`
- :ref:`jinja:filters`
- `More on Jinja Filters`_
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated link. this used :ref: before which is a local page link. I also fixed the URL to the jinja template page

@@ -321,6 +321,6 @@
# Example configuration for intersphinx: refer to the Python standard library.
intersphinx_mapping = {
'python': ('https://docs.python.org/3.6', None),
'jinja': ('http://jinja.pocoo.org/docs/dev', None),
'jinja': ('https://jinja.palletsprojects.com/en/latest/', None),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect this was failing because the URL was a redirect and builds don't like redirects. maybe it was just a front end redirect which can cause problems. the url above is correct.

capable of passing additional information to the Jinja
templating engine.

Parameters
----------
preprocessor : `Preprocessor`
preprocessor : `nbconvert.preprocessors.Preprocessor`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not sure if this is the correct preprocessor object. It is either this or .base.Preprocessor. but this was causing the docs to fail too.

@@ -316,7 +316,7 @@ def _preprocess(self, nb, resources):
# to each preprocessor
for preprocessor in self._preprocessors:
nbc, resc = preprocessor(nbc, resc)
try:
try:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my text editor Atom must do something with spaces. i hope this isn't problematic. if it is i can try to fix it.

@lwasser
Copy link
Contributor Author

lwasser commented May 18, 2021

ok the new point of failure is similar to the original issue i fixed. this is a simple docstring fix if we can identify which exporter object to use
exporters.TemplateExporter OR templateexporter.TemplateExporter

/root/checkout/docs/source/api/filters.rst:6:more than one target found for 'any' cross-reference 'TemplateExporter': could be :py:class:`nbconvert.exporters.TemplateExporter` or :py:class:`nbconvert.exporters.templateexporter.TemplateExporter`

Which one is the right one? NOTE i don't get this error building locally!
Actually looking more closely this fail is different from the last i think.

@lwasser
Copy link
Contributor Author

lwasser commented May 18, 2021

ok i may need input from you @MSeal or @yuvipanda this seems to be a circular problem. once i fix a reference in a doc i get a new one. The nature of each issue is a potentially duplicative reference to an object that has a base object with the same name and then maybe on that inherits or something - like the warning (treated as an error) below. i'm not familiar with the extension that is testing your docstrings for objects. and each time i've guessed which object is the correct one. the base one or the inherited one. i'm open to any input and also open to undoing anything ive done so far. i am confident that the jinja fixes are good. but i cant replicate the other issues (like the one pasted below here) locally to troubleshoot.

/root/checkout/docs/source/architecture.rst:64:more than one target found for 'any' cross-reference 'Exporter': could be :py:class:nbconvert.exporters.Exporter or :py:class:nbconvert.exporters.exporter.Exporter``

sphinx-doc/sphinx#4961

@MSeal
Copy link
Contributor

MSeal commented Jun 7, 2021

Sorry it took a while for me to get back to this thread. I was able to get the builds working with all but the fitlers.rst nbconvert.exporters.templateexporter.TemplateExporter. I can't figure out why it dislikes that type reference after trying a few approaches, so I changed that one to a non-linked code reference and it appears to be the last issue in the docs locally.

@MSeal MSeal marked this pull request as ready for review June 7, 2021 01:21
@MSeal
Copy link
Contributor

MSeal commented Jun 7, 2021

Can't seem to get the errors to occur locally, so I have to keep pushing fixes :/

@MSeal MSeal mentioned this pull request Jun 7, 2021
@lwasser
Copy link
Contributor Author

lwasser commented Jun 7, 2021

@MSeal I had the same issue - i think the errors are related to this sphinx issue but i noticed the docs are not updating so my guess i s until this is fixed they wont build on readthedocs

@lwasser
Copy link
Contributor Author

lwasser commented Jun 7, 2021

one thing i find odd is it's flagging files that are just code not even references in docstrings. i stopped when i noticed that because i wasn't sure if/how we wanted to fix that! it seems like sphinx should ignore that type of issue or have an option to ignore it.

@MSeal
Copy link
Contributor

MSeal commented Jun 8, 2021

Yeah, we have all warnings as errors causing the build annoyance. Most of the references are in the changelog, but for now until that reference issue is resolved in sphinx I'm just going to change them to non-references for now to unblock.

@MSeal
Copy link
Contributor

MSeal commented Jun 8, 2021

Uhg, 'CellExecutionError' is being pulled in from nbclient which is outside the repo's ability to directly control

@MSeal
Copy link
Contributor

MSeal commented Jun 8, 2021

My local sphinx was on 3.x, upgrading to 4.x explicitly gets the errors to occur. I fixed all the ones not brought in but didn't know a way to get around the imported reference issues so I turned off warnings as errors for now

@MSeal MSeal merged commit 76bfbb5 into jupyter:main Jun 8, 2021
@MSeal MSeal added this to the 6.1 milestone Jun 8, 2021
@lwasser
Copy link
Contributor Author

lwasser commented Jun 8, 2021

oh wow - docs built?! i'll check read the docs !! this is great @MSeal thanks! what a pain to fix all of those references!

@lwasser
Copy link
Contributor Author

lwasser commented Jun 8, 2021

yay! docs updated finally!! 🎆

@MSeal
Copy link
Contributor

MSeal commented Jun 8, 2021

Yeah! I ended up having to disable warnings as errors until sphinx-doc/sphinx#4961 is resolved as the remaining references are coming from nbclient can't be eliminated locally to nbconvert.

@lwasser
Copy link
Contributor Author

lwasser commented Jun 8, 2021

oh... good call. Yes that is really an annoying bug in sphinx right now! glad you were able to figure out how to just turn that off for the time being!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants